Enable Glagol support by translating slashes in identifiers to dots #136
Conversation
|
-1. I don't think your only incentive ("looks better for file loading in glagol") is enough to introduce such a big change. |
|
I fail to see how this is anywhere close to a big change: it's pretty much inconsequential outside of the stated use case, and does not make any less sense than the current behavior. On the other hand, I feel like I'm onto something with Glagol, and would like it to offer first-class support for Wisp. (To clarify, path literals are such a central feature because they always return the up-to-date result of evaluating that file, rather than just load its source text and call it a day.) I am open to suggestions though. If there is a more semantic way to add relative path literals to the language, I could give it a go. But it seems that dispatching in reader.wisp is hardcoded and there is no function that corresponds to |
|
It's a big change because, as you stated, it parts way with the cljs way (whIch uses / for namespacing) |
This is a patch which allows for compatibility with Glagol, a clever little live coding framework that I've been working on for the last few months. One of its main features actually originated from this very hack; turns out that replacing slashes with dots allows
(./foo/bar baz)to be translated to_.foo.bar(baz)rather than the nonsensical_.foo/bar(baz). This is not only more consistent with how namespaces are currently handled in Wisp, but, in Glagol, allows you to use a path-like syntax to get the values of neighboring files (which are helpfully provided by Glagol in a_global object.)I understand that this is a somewhat weird feature and not consistent with the Clojure side of things (AFAIK Clojure does not support anything like nested namespaces). Still, I consider it beneficial to contribute this to upstream, so that Glagol can support Wisp out-of-the-box without having to maintain a patched fork. (I actually tried monkeypatching the writer at runtime -- but, within the writer module, the original
varreference to the unpatched function was preserved, so it didn't work).I have also fixed an assumed typo in the docstring for
translate-identifier-word.